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Eauipement et procede de qestion d'informations d'etat pour la 
transmission de donnees dans un r'seau telephonique 

La presente invention concerne la transmission de donnees dans un 
5 reseau telephonique de transmission de donnees. 

Les reseaux telephoniques ont initialement offert essentiellement un 
service de transmission de la voix, associe a un service de transmission de 
donnees n'offrant qu'un debit tres limite. On peut par exemple songer au 
service Minitel. 

10 Les reseaux radiotelephoniques apparus ensuite, comme le reseau 

GSM, ont de meme offert un canal de transmission de donnees a faible debit. 

Les utilisateurs pouvaient ainsi emettre des messages courts SMS. 

Avec le developpement du reseau informatique Internet, il est apparu 

que les reseaux telephoniques ne pouvaient satisfaire les besoins des abonnes 
15 en bande passante et en types de protocoles pour des echanges de donnees a 

haut debit, c'est-a-dire pour transmettre rapidement des fichiers de volume 

important. 

Dans le cas des reseaux radio, le developpement du reseau GPRS 
vise a apporter une amelioration, par le fait qu'il offre une bande passante 
20 accrue, en attendant le reseau UMTS. 

La transmission des donnees dans les reseaux s'effectue maintenant 
en mode paquet, ce qui autorise les terminaux a rester connectes en 
permanence au reseau, puisqu'ils n'en immobilisent pas les ressources en 
I'absence de transmission de paquets. Les terminaux restent virtuellement 
25 connectes et ils peuvent ainsi etre joints sans delai. 

Cette possibility d'acces rapide aux terminaux permet d'offrir de 
nouveaux services, par exemple la fourniture automatique de donnees 
d'information depuis des serveurs specialises. L'utilisateur d'un terminal peut 
ainsi par exemple s'abonner aupres d'un fournisseur de service lui indiquant 
30 sans delai I'apparition d'evenements d'un type determine, par exemple des 
evenements sportifs, politiques, ou encore le franchissement d'un seuil de 
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cours cTune valeur en bourse. Ce type de service est appele « push » 
(pousser), du fait que Information est « poussee » automatiquement vers le 
terminal sans que son utilisateur ait besoin de la demander expressement, 
c'est-a-dire sans devoir la « retirer » du serveur. L'exploitation « push » evite 

5 ainsi les requetes inutiles de la part de I'utilisateur pour s'enquerir de i'existence 
eventuelle d'informations en attente dans le serveur. Le terminal regoit ainsi 
automatiquement les donnees d'information, en mode masque a I'utilisateur, et 
il le signale ensuite a celui-ci. 

Hormis la convivialite que cela apporte, I'absence de telles requetes 

10 evite aussi I'encombrement du reseau. Toutefois, comme le serveur emet les 
paquets d'informations a des instants aleatoires, sans aucune concertation ou 
synchronisation avec le terminal destinataire, cette emission de donnees 
d'information intervient parfois lorsque le terminal communique par ailleurs 
avec un correspondant en echangeant des paquets de donnees. Le trafic du 

is terminal se trouve ainsi momentanement accru pendant la reception des 
informations provenant du serveur, ce qui peut provoquer une degradation de 
la qualite de service. 

Cette degradation peut se manifester par des collisions entre 
applications et par des fluctuations reduisant le debit des donnees echangees 

20 avec le correspondant, c'est-a-dire un accroissement des temps de 
chargement. Cela represente une gene nettement perceptible dans le cas de 
gros fichiers de donnees, echanges avec le correspondant ou regus du serveur. 
Le meme probleme se poserait si le terminal appelait cycliquement et 
automatiquement le serveur pour s'enquerir de 1'existence de donnees a retirer 

25 (« pull »). 

En outre, il se peut que le terminal se trouve temporairement isole du 
reseau, par le fait que son utilisateur Pa mis en veille ou que, dans le cas d f un 
reseau radiotelephonique, il est sorti des zones radio couvertes. En pareil cas, 
les appels du serveur encombrent inutilement le reseau et en consomment les 
30 ressources. 

La presente invention vise a permettre, dans le cadre d'un echange 
automatique de donnees, a des instants a priori aleatoires, entre un terminal et 
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un serveur, en mode masque a I'utilisateur du terminal, d'eviter de perturber le 
trafic du reseau et en particulier, mais non exclusivement, le trafic du terminal. 

A cet effet, I'invention concerne tout d'abord un procede de 
transmission de donnees dans un reseau telephonique de transmission de 
5 donnees, depuis un serveur vers au moins un terminal du reseau, caracterise 
par le fait que : 

le serveur acquiert, en provenance d'organes de transmission de 
trafic du reseau, des informations d'etat du reseau, et 

le serveur compare les informations d'etat du reseau a au moins 
10 un critere pre-etabli d'etat du reseau, pour retarder la transmission des 
donnees tant que I'etat du reseau ne repond pas a I'au moins un critere d'etat. 

Les informations d'etat du reseau peuvent concerner globalement le 
reseau mais aussi les liaisons terminates reservees a un certain nombre de 
terminaux respectifs, pour lesquels le reseau peut determiner des informations 
15 d'etat specifiques a I'activite telephonique du terminal et les fournir a titre 
d'informations d'etat du reseau. 

On notera que, par terminal, on entend designer tout type d'equipement 

relie au reseau. 

Ainsi, alors qu'un terminal ne fournit au serveur aucune information sur 
20 son etat d'accessibilite et d'occupation, qui permettrait au serveur d emettre aux 
instants les plus favorables, c'est le reseau lui-meme qui fournit ce type 
d'informations, permettant done au serveur de se synchroniser de facon que 
son trafic soit emis en quelque sorte en opposition de phase avec celui du 
terminal, ou au moins ses pointes de trafic, et cette emission intervenant a bon 
25 escient, lorsque ce dernier est relie au reseau. Bref, le serveur peut ainsi 
n'emettre que lorsque le terminal dispose, pour la reception, des ressources 
reseau necessaires, en bande passante ou en puissance de traitement. De 
meme, le reseau peut signaler au serveur que son infrastructure est proche de 
la saturation, pour ainsi commander un lissage de son trafic, en commandant 
30 au serveur de retarder son emission. 

On peut considerer que I'invention consiste a integrer fonctionnellement 
le serveur dans un reseau de signalisation semaphore, « couvrant », ou 
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doublant, la partie transmission du reseau concerne, pour ainsi disposer des 
informations voulues sur I'etat du reseau telephonique. On rappellera qu'un 
reseau de signalisation semaphore sert entre autres a detecter I'etat 
d'occupation d'un terminal appele, et a le faire sonner, une voie de 
communication de parole n'etant etablie qu'en cas de reponse de I'appele. On 
evite ainsi des allocations inutiles de ressources du reseau. De facon classique, 
les reseaux semaphores sont de type ferme, leurs informations etant 
exclusivement reservees aux centraux du reseau. 

II convient de noter que I'invention couvre aussi des variantes de la 
technique "push". En effet, le probleme a I'origine de la presente invention 
concerne le fait que le serveur provoque une augmentation de trafic au niveau 
du terminal. Toutefois, les donnees emises par le serveur peuvent n'avoir qu'un 
effet indirect sur le trafic, en n'etant que de simples telecommandes, 
commandant au terminal de se relier a un autre correspondant, serveur ou 

autre, pour echanger des donnees, dans un sens ou I'autre. Bref, le domaine 

de I'invention n'est pas limite au mode "push". 

L'invention peut avantageusement etre mise en oeuvre au moyen d'un 

gestionnaire effectuant ('acquisition des informations d'etat et les 

retransmettant au serveur. Le gestionnaire, localise ou reparti, peut etre un 

serveur du reseau ou etre integre, ou associe, au serveur utilisateur. 

Dans un mode de mise en oeuvre du procede, le reseau acquiert au 

moins une partie des informations d'etat aupres d'organes de transmission qui 

sont des centres de commutation du reseau. 

En variante ou en complement, le reseau acquiert au moins une partie 

des informations d'etat au moyen de sondes de surveillance de trafic disposees 

sur des arteres de communication du reseau, en particulier aux differentes 

interfaces suivantes : 

- les interfaces Air (ou Urn), situees chacune entre une station mobile 
(MS) et la station de base (BTS) de la cellule geographique dans laquelle se 
trouve cette station mobile, 

- les interfaces Abis, situees chacune entre une station de base (BTS) 
et le controleur de station de base (BSC) correspondant, 
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- les interfaces A, situees chacune entre un controleur de station de 
base (BSC) et le commutateur du service mobile (MSC) correspondant, 

- les interfaces "CCITT n° 7 telephonique" (ISUP, TUP, SSUTR2), 
situees chacune entre un commutateur du service mobile (MSC) et un centre 

5 de transit, 

- les interfaces MAP (pour Mobile Application Part en langue anglaise), 
situees chacune entre un commutateur du service mobile (MSC) et une base 
de donnees specialisee (HLR, VLR, AuC, EIR). 

Le serveur ou le gestionnaire peut etre prevu pour requerir du reseau 
10 des informations d'etat voulues, et en particulier commander, dans le reseau, la 
fourniture en retour d'informations de rafraichissement d'informations d'etat, 
par exemple par envoi, dans le reseau, de stimuli d'activation du terminal. Les 
stimuli provoquent I'etablissement d'un contexte d'une nouvelle liaison de 
donnees dans le reseau, contexte qui est detecte pour effectuer un 
15 rafraichissement des informations d'etat du reseau specifiques au terminal. 

En pareil cas, selon un premier mode, les stimuli activent une 
application du terminal, par exemple une application SIM Toolkit. 

Selon un second mode, les stimuli atteignent d'abord un centre de 
commutation du reseau et lui commandent de les transformer en un message 
20 emis d'activation du terminal, lui notifiant qu'il doit appeler un centre, pour y 
recuperer des donnees. 

On concoit que I'invention s'applique parfaitement, mais de facon non 
limitative, aux reseaux cellulaires, par exemple GPRS ou UMTS, mais qu'elle 
s'applique aussi aux reseaux radio formes d'une constellation de satellites. 
25 L'invention concerne aussi un gestionnaire d'informations d'etat d'un 

reseau telephonique pour la mise en ceuvre du procede de I'invention, 
comportant des moyens de gestion agences pour recevoir des informations 
d'etat du reseau et les retransmettre a des serveurs de donnees d'information. 

L'invention sera mieux comprise a I'aide de la description suivante d'un 
30 reseau dans lequel est mis en ceuvre le procede de l'invention, en reference au 
dessin annexe, sur lequel : 
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- la figure 1 est une vue tres schematique representant un reseau de 
radiotelephonie, ici le reseau cellulaire GPRS, relie, dans I'exemple a 
travers un gestionnaire des informations d'etat du reseau, a un serveur 
de fourniture de donnees d'information en mode « push » mettant en 
oeuvre le procede de ('invention, 

- la figure 2 represente le reseau de la figure 1 et illustre un procede de 
recuperation d'informations d'etat du reseau, selon un premier mode, 
aupres de centres de commutation du reseau, 

- la figure 3 illustre le procede de recuperation d'informations d'etat du 
reseau, selon un second mode, par des sondes disposees sur des 
arteres du reseau (interfaces), 

- la figure 4 est un diagramme d'echange de signalisations illustrant un 
procede de rafraichissement des informations d'etat du reseau, 
rafraichissement provoque par renvoi, depuis le gestionnaire, de stimuli 
d'activation du terminal qui, dans un premier mode de mise en oeuvre, y 
activent une application afin de provoquer de sa part Tetablissement 
d'une liaison en vue d'analyser des caracteristiques du trafic 
correspondant, et 

- la figure 5 est un diagramme homologue de celui de la figure 4, illustrant 
un second mode de mise oeuvre du procede de rafraichissement ci- 
dessus, correspondant a des stimuli commandant, dans les centres de 
commutation du reseau, renvoi d'un message vers un terminal vise, lui 
notifiant que des donnees, dont il est destinataire y sont en attente. 

L'infrastructure pour la mise en oeuvre de invention va d'abord etre 
decrite et son fonctionnement explique, puis les deux procedes ci-dessus vont 
successivement etre exposes, dans chacun de leurs deux modes. 

La figure 1 represente un reseau telephonique de transmission de 
donnees 1, et plus precisement dans cet exemple un reseau radiotelephonique 
qui est ici cellulaire, a savoir le reseau GPRS, qui s'appuie sur l'infrastructure 
du reseau GSM. 
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Le choix d'un reseau de type radio dans cet exemple provient du fait 
qu'il permet d'exposer en particulier le cas, relativement frequent, d'un terminal 
radio mobile non localise, c'est-a-dire temporairement non rattache ("idle") au 
reseau 1, du fait d'un passage dans une zone d'ombre ou par une action 

5 volontaire de I'utilisateur, qui en a coupe I'alimentation. Un cas homologue a ce 
dernier cas peut toutefois se presenter dans un reseau filaire, par exemple en 
presence d'un bus de type SO, sur lequel plusieurs terminaux peuvent 
individuellement etre raccordes et deconnectes ou mis hors tension. 

Un serveur de donnees 3 est relie au reseau 1 pour acceder a des 

10 terminaux mobiles 1 1 , dont un seul est represents. Le serveur 3 comporte une 
unite centrale 31 commandee par des logiciels d'une memoire 32, une table 33 
de criteres (au moins un) d'etat du reseau 1 , accessible par les logiciels de la 
memoire 32 et une memoire de donnees a emettre 34. 

Dans cet exemple, le serveur 3 est relie au reseau 1 a travers un 

15 gestionnaire d'interface ou frontal 2 de gestion d'informations d'etat du reseau 
1, c'est-a-dire que I'acquisition des informations d'etat par le serveur 3 
s'effectue ici a travers le gestionnaire 2. Le gestionnaire 2 comporte une unite 
centrale 21 commandee par des logiciels d'une memoire 22, et une memoire 
23 de donnees d'etat du reseau 1. Par commodite, les logiciels en memoire 

20 portent ici la meme reference que celle-ci mais entre parentheses. Les logiciels 
(22) comprennent entre autres : 

- des logiciels 221 d'interrogation sur I'etat du reseau 1 , 

- des logiciels d'activation 222 agences pour lancer dans le reseau 1 des 
stimuli de rafraTchissement des informations d'etat, 

25 - des logiciels 223 d'agregation d'informations d'etat du reseau 1, afin de 
fournir au serveur 3 des donnees de synthese de I'etat, et 

- des logiciels 224 d'integration, dans le temps, d'informations d'etat du 
reseau, afin de fournir au serveur 3 des donnees de synthese de I'etat. 

Une memoire de travail, non representee, de I'unite centrale 21 stocke 
30 les diverses commandes ou requetes ou signaux de signalisation equivalents 
echanges avec le reseau 1 et avec le serveur 3. Les moyens materiels et 



logiciels d'interface de communication du gestionnaire 2 et du serveur 3 ne sont 
pas ici dessines et decrits, car I'invention ne porte pas specifiquement sur eux. 

La presence du gestionnaire 2 dans cet exemple presente I'avantage 
de centraliser les taches de gestion, afin d'eviter au maximum des 
5 modifications a cet effet dans le reseau 1. Cela permet en outre un travail en 
temps masque d'echange de donnees avec le reseau 1. 

Les donnees d'information du serveur 3 peuvent etre de tout type de 
fichier, que ce soit du texte, de la telecopie, des signaux sonores ou de I'image. 
Comme on le verra par la suite, leur nature peut toutefois avoir une influence 
10 perturbatrice plus ou moins forte dans le reseau 1 et en particulier au niveau du 
terminal 11, du fait du volume de donnees implique et du protocole utilise, 
susceptible d'y consommer trop de ressources de traitement. 

Vis-a-vis du reseau 1, le gestionnaire 2 peut etre fonctionnellement 
considere de deux fagons differentes. D'une part, le gestionnaire 2 peut etre 
15 considere comme une interface associee au serveur 3, interface disposant, 
aupres du reseau 1, de droits pour I'interroger sur son etat D'autre part, et bien 
que dessine en dehors du reseau 1, le gestionnaire 2 peut etre considere 
comme faisant fonctionnellement partie du reseau 1, en tant que serveur 
specialise pour repondre au serveur 3. II en est de meme pour une liaison radio 
20 1 3 reliant le terminal 1 1 au reseau 1 . 

Le serveur 3 est en fait relie au reseau 1 par deux types de liaisons. 
Une liaison 12, 28 du premier type, principalement sortante vis-a-vis du reseau 
1, traverse, comme represents, le gestionnaire 2 et concerne la fourniture, au 
serveur 3, d'informations sur I'etat du reseau 1, fournies par celui-ci, pour 
25 mettre en oeuvre le procede de I'invention. II s'agit d'informations equivalentes 
(apres traitement eventuel) a des signaux de service, a partir desquelles le 
serveur 3 elabore des commandes regulant, sur une liaison du second type 29, 
principalement entrante vis-a-vis du reseau 1, un flux de donnees d'information 
transmises automatiquement, en mode « push », vers les terminaux 11. La 
30 liaison du second type 29 est done asservie par la liaison du premier type 28, 
qui joue le role d'une liaison semaphore, gerant le flux incident dans le reseau 1 
et ainsi evitant au mieux les contentions. On notera a ce sujet que le 
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gestionnaire 2 pourrait aussi etre utilise par les divers centres du reseau 1 , pour 
d'eventuels echanges de donnees hors temps reel, par exemple des fichiers de 
facturation. 

On peut done considerer que le reseau 1 commande lui-meme, par les 
informations qu'il fournit sur la liaison sortante 12, 28, le volume de trafic qu'il 
recoit par la liaison en rebouclage 29. La liaison entrante 29 a done 
volontairement ete dessinee comme ne traversant pas le gestionnaire 2, qui 
n'agit qu'en amont (28) de celle-ci, bien que rien n'interdise que la liaison 29 
traverse aussi le gestionnaire 2. Les liaisons logiques de donnees 28 et 29 
peuvent etre etablies sur toute sorte de support de transmission, par exemple 
une voie radio ou bien filaires et eventuellement portees dans ce cas par un 
meme support physique, tel que paire torsadee, coaxial, fibre optique. 

Comme expose plus haut, le concept de I'invention est de foumir au 
serveur 3 des informations sur I'etat du reseau 1 , y compris celui des liaisons 
comme la liaison 13 du terminal 11. 
Pour cela : 

- le serveur 3 acquiert, en provenance d'organes (14 a 18, fig. 2) de 
transmission de trafic du reseau 1, des informations d'etat du reseau 1, 
et 

- le serveur 3 compare les informations d'etat du reseau 1 a au moins un 
critere pre-etabli d'etat du reseau 1, de la table 33, pour retarder la 
transmission des donnees tant que I'etat du reseau 1 ne repond pas a 
I'au moins un critere d'etat. 

Les informations d'etat peuvent concerner, comme deja indique, le 
reseau 1 dans sa globalite tout aussi bien que certains terminaux 11 identifies, 
par exemple designes prealablement par le serveur 3. Les informations d'etat 
peuvent ainsi concerner les niveaux de charge de divers centres 14 a 18 de 
commutation du reseau 1, I'etat d'occupation de la liaison 13 du terminal 11, 
I'intensite de son trafic eventuel ou encore le(s) type(s) de protocole(s) actif(s) 
sur la liaison 13, HTTP, FTP, par exemple, ce qui fournit une indication sur le 
taux de charge de traitement d'un processeur de communication du terminal 11 
et done sur son aptitude a recevoir, en plus, le flux des donnees d'information 



10 



en attente dans le serveur 3. Par exemple, le protocole FTP monopolise toutes 
les ressources du terminal 11, et une emission des donnees du serveur 3 dans 
cette periode serait done nefaste. Vindication, dans les informations d'etat 
fournies au serveur 3, de I'utilisation du protocole FTP par le terminal 1 1 cible 

5 est un critere de saturation du terminal 1 1 qui, par consultation de la table 33, 
interdit remission des donnees du serveur 3. L'instant d'emission est done 
reporte jusqu'a un instant ulterieur pour lequel le protocole FTP sera indique 
comme n'etant pas utilise, et dans la mesure ou d'autres criteres requis seront 
aussi satisfaits, par exemple le fait que le terminal 1 1 est joignable ou encore 

10 que le reseau 1 ne presente pas de niveau de saturation de trafic depassant un 
seuil haut. 

La table 33 contient ainsi au moins un critere de regulation du trafic 
susceptible d'etre injecte dans le reseau 1. De preference, il est prevu une 
pluralite de tels criteres, exploites par les logiciels (32). 

15 Les logiciels (32) comparent les « valeurs » des informations d'etat 

recues a des valeurs homologues de la table 33 pour decider d'envoyer 
immediatement les donnees en attente ou au contraire d'en differer remission 
si Tun au moins des criteres n'est pas satisfait. Un critere d'une telle decision 
peut, dans certains cas, etre un resultat d'une combinaison de plusieurs types 

20 d'informations brutes, ou primaires, qui sont ainsi ponderees. 

La table 33 peut meme se substituer au moins partiellement aux 
logiciels 32 en constituant elle-meme une table de decision, e'est-a-dire une 
sorte de logique combinatoire, du genre FPLA (reseau logique programmable), 
recevant les informations d'etat des divers types et les combinant selon des 

25 regies pre-etablies pour fournir directement en sortie une autorisation 
d'emission des donnees en attente dans la memoire 34. 

Le reseau 1 peut ainsi, entre autres, determiner des informations d'etat 
specifiques a I'activite telephonique du terminal 11 et les fournir a titre 
d'informations d'etat du reseau 1. Ainsi, le reseau 1 determine, comme 

30 informations specifiques au terminal 11, au moins I'un des types d'informations 
suivants : 



i er uepox 

11 



- etat de charge de trafic d'un centre de commutation SGSN (fig. 2) 
auquel est rattache le terminal 1 1 , 

- etat d'accessibilite du terminal 1 1 (Idle/ Ready/ Standby), 

- etat d'occupation du terminal 11, en particulier echange courant d'un 
trafic de donnees, et si tel est le cas le type de protocole utilise (ftp, 
http,...), 

- debit montant du terminal 11 vers le centre de commutation, ou 
rattachement, SGSN, 

- debit descendant du centre de commutation SGSN vers le terminal 1 1 , 

- qualite de service allouee a I'utilisateur du terminal 1 1 . 

Le reseau 1 peut surveiller des changements des informations d'etat et 
emettre automatiquement, a destination du serveur 3, done ici vers le 
gestionnaire 2, une notification de changement d'etat necessitant un 
rafraichissement des informations d'etat precedemment acquises. Le reseau 1 
peut en particulier notifier spontanement au gestionnaire 2 la mise a jour des 
informations d'etat ayant change. 

Le gestionnaire 2 recoit ainsi du reseau 1 et stocke en memoire 23 les 
informations d'etat, pour ensuite les retransmettre au serveur 3, sur requete ou 
spontanement. 

Les moyens de gestion 21 , 22, 23 permettent ainsi au gestionnaire 2 de 
recevoir les informations d'etat du reseau 1 et les retransmettre a des serveurs 
de donnees d'information 3, le logiciel 221 permettant Interrogation du reseau 
1 sur son etat. 

Le logiciel d'activation 222 permet en outre de lancer dans le reseau 1 , 
comme explique plus loin, des stimuli de rafraichissement des informations 
d'etat. 

Pour mieux mettre en valeur les informations d'etat, le logiciel 223 
agrege les informations d'etat du reseau 1, afin de fournir des donnees de 
synthese de I'etat, sous la forme par exemple de valeurs d'un indice de 
disponibilite du terminal 11. L'indice a ici cinq niveaux, correspondant a un 
terminal : 
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- Indice 0 : joignable et non actif, 

- Indice 1 : terminal joignable mais faible. utilisation des ressources 

(messagerie instantanee), 

- Indice 2 : joignable mais avec des ressources reseau limitees, 

5 - Indice 3 : joignable avec des ressources reseau utilisables et utilisees 

pleinement (FTP, ...), 

- Indice 4 : non joignable. 

Dans le meme but, le logiciel 224 integre, dans le temps, les 
informations d'etat du reseau 1, type par type, afin de fournir au serveur 3 des 
io donnees de synthese de I'etat du reseau 1. 

Le procede d'acquisition, ou d'extraction, des informations d'etat du 
reseau 1 va maintenant etre expose, dans ses deux modes de mise en ceuvre. 

Premier mode du procede d'acquisition des informations d'etat du 
reseau 1 (fig. 2). 

15 Le reseau 1 peut acquerir au moins une partie des informations d'etat, 

par exemple la « presence GPRS » d'un terminal 11, par interrogation de 
centres de commutation du reseau 1 adaptes a cet effet. Sur la figure 2, les 
r £f£ rences 14, 15 et 16 designent des centres terminaux de commutation, ou 
de rattachement cellulaire, appeles SGSN (noeuds de service GPRS), gerant 

20 les terminaux 11 d'une cellule particuliere a chacun. Les references 17 et 18 
designent des centres nodaux GGSN (noeuds passerelle GPRS) 
respectivement relies aux centres SGSN 14 a 16 et les federant par des arteres 
de communication haut debit 41, 42, 43 et 44, 45, 46, de divers types de 
supports physiques. La reference 19 designe un centre de gestion HLR pour la 

25 localisation des terminaux 1 1 entre les differentes cellules. 

En pareil cas, le gestionnaire 3 interroge les centres ci-dessus les plus 
pertinents, ou en recoit des emissions spontanees. 

Le reseau 1 acquiert au moins une partie des informations d'etat 
aupres des centres de commutation du reseau, ici des centres de rattachement 

30 SGSN 14, 15, 16 des terminaux 11. Chaque centre SGSN 14, 15, 16 du reseau 
1 stocke localement et transmet a destination du serveur 3, done ici vers le 
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gestionnaire 2, pour chaque terminal 11 rattache a I'un des centres 14, 15, 16, 
au moins I'un des types d'informations d'etat suivants : 

- identifiant unique du terminal (IMSI, MSISDN), 

- etat d'accessibilite du. terminal : « MM State » : hors service (idle), done 
non joignable, repos (standby), actif (ready), done joignable dans ces 
deux cas, 

- localisation du terminal (par definition de la zone de routage (routing 
area), le numero de cellule courante (cell-ID) lorsque le terminal est en 
mode « READY » ou la derniere cellule connue si le terminal est en 
mode repos (standby) ou hors-service (idle), 

- temps de repos courant du terminal (Cellldentity-Age) ou duree depuis le 
dernier transfert de donnees, 

- nombre de contextes PDP (Protocole Reseau par Paquets) e'est-a-dire 
de liaisons logiques, 

- etat de chaque contexte PDP (Actif ou Inactif), 

- adresse(s) PDP allouee(s), 

- niveau de qualite alloue, 

- trafic montant 

- trafic descendant, sous la forme eventuellement d'informations 
« amont » permettant de deduire le trafic montant et descendant, 
comme Emission du numero N-PDU d'unite de donnees de protocole : 
« Send N-PDU Number » et Reception du numero N-PDU « Receive N- 
PDU Number ». 

Dans une forme d'exploitation, les centres 14 a 16 surveillent I'etat 
courant des informations d'etat pour les comparer a des informations d'etat 
precedentes stockees localement, afin, en cas d'evenement de changement 
d'etat, d'effectuer un rafraichissement des informations stockees localement et 
de declencher d'eux-memes, a destination du serveur 3, ici a travers le 
gestionnaire 2, une emission des informations d'etat courantes. 



Parmi les evenements a surveiller au niveau des centres 14 a 16 qui 
peuvent induire des changements d'etat, on peut mentionner de maniere non 
exhaustive les evenements suivants : 

- changement d'etat d'accessibilite du terminal 11, c'est-a-dire son etat 
5 GPRS, 

- rattachement du terminal a un autre centre 14 a 16, 

- changement de zone de routage, 

- debut, interruption ou fin d'un transfert de donnees, 

- renegociation d'un niveau de qualite de service QoS (Quality of Service), 
10 - activation ou deactivation d'un contexte de liaison. 

La transmission, a destination du serveur 3, des informations stockees 
localement dans un centre 14 a 16 peut toutefois s'effectuer sur requete du 
gestionnaire 2, repetant eventuellement une meme requete issue du serveur 3. 
Dans le second mode de mise en oeuvre du procede d'acquisition des 

15 informations d'etat du reseau 1 (figure 3), le reseau 1 acquiert au moins une 
partie des informations d'etat au moyen de sondes 51 a 56 de surveillance de 
trafic disposees sur les arteres de communication 41 a 46 respectives du 
reseau 1, reliant les centres nodaux GGSN 17, 18 aux divers centres de 
rattachement 14 a 16. Les arteres surveillees peuvent etre les arteres 41 a 46 

20 dans leur partie liaison, ou, en cas d'impossibilite (fibres optiques) ou pour plus 
de facilite, leurs extremites de depart ou d'arrivee, ou encore les 
interconnexions correspondantes, dans les centres nodaux GGSN 17, 18 ou 
autres routeurs. II s'agit done d'une analyse en temps reel des champs de 
signalisation ou de donnees des messages de signalisation et de donnees 

25 transitant dans le reseau federateur GPRS. Un tel second mode, a base de 
sondes 51 a 56, evste ainsi la necessite de modifications dans les centres 14 a 
18 du reseau 1. Le rattachement, tel que dessine, des sorties des sondes 51 a 
56 au gestionnaire 2, n'est que schematique, et emprunte en pratique des voies 
du reseau 1. 

30 Les sondes 51 a 56 analysent des champs de signalisation de 

messages transitant sur les arteres 41 a 46 pour en extraire au moins certaines 



15 



des informations d'etat concernant les terminaux 1 1 , dans la mesure ou ils sont 
actifs. Les en-tetes de paquets selon le protocole GTP (GPRS Tunel Protocole) 
permettent par exemple d'identifier les terminaux 11 d'apres leur numero 
d'identification unique IMSI dans un champ TID. Les sondes 51 a 56 analysent 
au moins Tune des signalisations suivantes du terminal 1 1 : 

- requete de creation de contexte de liaison, par une commande Create 
PDP Context Request/Response, 

- requete de mise a jour de contexte de liaison, par une commande 
Update PDP Context Request/Response, 

- requete d'effacement de contexte de liaison, par une commande Delete 
PDP Context Request/Response, 

- requete de notification PDU, par une commande PDU Notification 
Request/Response, 

- requete d'emission d'informations de routage reseau, par une 
commande Send Routing Information for GPRS Request/Response, 

- requete pour noter qu'un terminal est a nouveau joignable, par une 
commande Note MS GPRS Present Request/Response, 

- requete d'identification, par une commande Identification 
Request/Response, et 

- requete de contexte SGSN, par une commande SGSN context 
Request/Response/Acknowledge. 

Les divers messages etant transmis selon divers protocoles, les sondes 
51 a 56 identifient le ou les protocoles utilises par une ou plusieurs liaisons 
logiques du terminal 1 1 . 

L'analyse des messages de signalisation GTP permet done d'avoir des 
informations sur la presence GPRS d'un abonne, sur son adressage (IP, X25) 
ainsi que sur la QoS dont il beneficie. Le protocole GTP adresse 
essentiellement la gestion des contextes PDP et les etats GPRS 
(Idle/Ready/Standby) sont deduits des messages lies aux contextes PDP. 
Ainsi, lorsqu'un contexte PDP est active, un utilisateur est joignable (etat 
Ready). Le fait qu'un utilisateur devienne joignable se traduit egalement par la 
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reception d'un message « Note MS GPRS Present Request » du HLR au 
GGSN via la passerelle MAG/GTP et egalement par des echanges inter SGSN 
lorsque I'attachement GPRS se fait sur un nouveau SGSN. 

Le rafraTchissement des informations d'etat du reseau 1 va maintenant 
5 etre explique. 

Le gestionnaire 2 peut requerir du reseau 1 des informations d'etat 
voulues, ceci suite a une requete du serveur 3 ou bien par une decision 
autonome. Le gestionnaire 2 peut en effet detecter que des informations d'etat 
qu'il a recues et stockees en memoire 23, avec des donnees horodatrices, sont 

10 obsoletes passe un certain seuil de peremption de duree de stockage, detecte 
par comparaison avec I'instant courant. 

Le gestionnaire 2 peut aussi recevoir du serveur 3 une requete pour 
des informations d'etat du reseau 1 non disponibles en memoire 23, et 
eventuellement non disponibles dans le reseau 1 , faute d'activite sur la liaison 

15 13 du terminal 1 1 , et done aussi inexistantes dans les arteres 41 a 46 en ce qui 
concerne le terminal 11. Le rafraTchissement n'est alors commande qu'apres 
reception, par le gestionnaire 2, d'une requete d'informations d'etat provenant 
du serveur 3. 

Le gestionnaire 2 commande alors, dans le reseau 1, un 
20 rafraTchissement des informations d'etat, e'est-a-dire un rafraTchissement 
d'informations d'etat precedemment recues ou la fourniture d'informations 
d'etat en complement de celles deja recues. 

Le gestionnaire 2 peut surveiller, dans le reseau 1 , la disponibilite des 
informations d'etat et il commande le rafraTchissement en cas d'indisponibilite 
25 de certaines des informations d'etat, faute par exemple de trafic du terminal 1 1 , 
comme indique ci-dessus. 

Le rafraTchissement des informations d'etat est commande par envoi, 
dans le reseau 1, de stimuli deactivation du terminal 11, pour I'activer afin de 
provoquer I'etablissement d'un contexte d'une nouvelle liaison de donnees PDP 
30 dans le reseau 1, et de detecter le contexte de liaison PDP pour effectuer un 
rafraTchissement des informations d'etat du reseau specifiques au terminal 11. 
C'est par exemple la localisation du terminal 1 1 au niveau d'une cellule (identite 
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de la cellule : Cell ID) au lieu d'une localisation plus globale, au niveau d'une 
zone de routage. Les deux modes possibles de mise en oeuvre du precede ci- 
dessus sont les suivants. 

Premier mode de mise en ceuvre du precede de rafraichissement des 

informations d'etat. 

Selon le premier mode, les stimuli activent une application du terminal 
11. II peut s'agir d'une application SIM Toolkit ou de toute autre application 
cliente dans le terminal 1 1 . Le terminal 1 1 , attache au reseau 1 d'un point de 
vue GSM, est ainsi appele en une sorte de « paging », par exemple au moyen 
de message SMS, SMSCB, USSD, ou autres. 

Cette application ouvre une liaison logique sur la liaison radio 13, par 
envoi au terminal 11 d'une commande « OPEN CHANNEL », ce qui amene la 
creation d'un contexte de liaison PDP, qui pourra etre detecte et examine par 
les centres 14 a 18 ou par les sondes 51 a 56, et ainsi fournir des informations 
d'etat rafraichies au gestionnaire 2. 

Si le terminal 1 1 est dans I'etat GPRS repos « idle », il s'attache au 
reseau 1 et devient ainsi joignable. Le terminal 11 passe alors a I'etat actif 
« ready », ce qui provoque la mise a jour de I'information de localisation a la 
cellule pres. 

Ensuite, le contexte PDP nouvellement engendre permet de rafraTchir 
des informations d'etat telles que le niveau de qualite de service QoS negocie 
entre le terminal 11 et le reseau 1 ainsi que I'adresse du terminal 1 1 et son 
type, tel que IP, X25. 

Des stimuli de deactivation de ('application peuvent etre ulterieurement 
emis par le gestionnaire 2 par exemple par une commande de « CLOSE 
CHANNEL » pour desactiver le contexte PDP, si une temporisation de 
commande de deactivation de I'application consideree n'est pas prevue. 

La figure 4 illustre un tel premier mode. 

Get exemple fait intervenir, de gauche a droite sur la figure, I'application 
GSM appelee SIM Toolkit, 111, le terminal mobile (MS) 11, le centre SGSN 14, 
la sonde 51 sur I'artere 41, le centre nodal GGSN 17 et le gestionnaire 2. 



Les huit etapes representees sont reperees de a) a h). Dans une 
premiere etape a), le gestionnaire 2 lance un appel (paging) vers I'application 
SIM Toolkit 111, afin de la declencher ou lance un message de Requete de 
mise a jour d'informations d'etat, « Update Information Request ». L'application 

5 111 repond, a une deuxieme etape b), par envoi d'un message « STK OPEN 
CHANNEL » au terminal 11. Ce dernier emet alors, a une troisieme etape c), 
une requete d'attachement « GMM Attach Request » au SGSN 14, qui lui 
repond, a une quatrieme etape d), par un message d'attachement « GMM 
Attach Response ». A une cinquieme etape e), le terminal 11 y repond par 

10 envoi d'un message de demande de creation de contexte de liaison PDP « SM 
Activate PDP Context Request ». A une sixieme etape f), cette requete remonte 
alors au GGSN 17 par I'artere 41, ou elle est detectee par la sonde 51 , dans un 
message de demande de creation de contexte PDP « GTP Create PDP 
Context Request », contenant un numero I MSI, une adresse PDP, et autres, 

15 qui sont des informations d'etat recherchees. Le centre GGSN 17 y repond, a 
une septieme etape g), par un message de reponse de creation de contexte 
« GTP Create Context Response », contenant un niveau de qualite de service 
QoS alloue, et autres informations d'etat. La sonde 51 recueille les informations 
d'etat ci-dessus et les transmet au gestionnaire 2, dans un message de 

20 rafraichissement « Update Information Request ». Le centre SGSN 14 envoie 
ensuite au terminal 11, a une huitieme etape h), un message « SM Activate 
PDP Context Response », fournissant le contexte requis. 

Second mode de mise en ceuvre du procede de rafraichissement des 
informations d'etat. 

25 Selon le second mode, la commande d'activation d'une application du 

terminal 11 s'effectue indirectement par activation d'une fonction de notification 

existant dans reseau 1 . 

Les stimuli atteignent d'abord un centre de commutation ou de 

rattachement du reseau 1, ici un centre nodal GGSN 17, 18, et lui commandent 
30 de les transformer en un message d'activation du terminal 11, qui lui est 

transmis et lui notifie qu'il doit appeler le centre nodal GGSN 17, 18 pour y 

recuperer des donnees. 
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La figure 5 illustre ce second mode. Ainsi, a une premiere etape A), le 
gestionnaire 2 envoie au centre nodal GGSN 17 un message de requete de 
mise a jour, ou rafraichissement, des informations d'etat, « Update Information 
Request, avec un numero IMSI de terminal 11. A une deuxieme etape B), le 
centre nodal GGSN 17 emet, vers le centre cellulaire SGSN 14 de 
rattachement du terminal 11, un message de Requete de notification GTP 
PDU : « GTP PDU Notification Request », contenant le numero IMSI, une 
adresse PDP, et autres . A une troisieme etape C), le centre cellulaire SGSN 
14 repond par un message de reponse en retour « GTP PDU Notification 
Response ». Ce message est detecte et analyse par la sonde 51, qui en 
recueille I'information de numero IMSI et extrait I'information de presence du 
terminal 11 dans la cellule du centre SGSN 14, ces informations etant 
retransmises au gestionnaire 2. Si le terminal est joignable, a une quatrieme 
etape D), le centre de rattachement SGSN 14 envoie au terminal 11 un 
message d'activation de contexte PD par Requete SM : « SM Request PDP 
Context Activation ». Les etapes cinq a huit suivantes sont semblables aux 
etapes e) a h) de la figure 4. 

De maniere generale, il a ete evoque une utilisation de ^infrastructure 
pour savoir quel est le moment le plus adapte pour transmettre des donnees a 
destination du client. Cependant, on peut egaiement mentionner ici d'autres 
utilisations de Infrastructure, comme par exemple : 

- I'adaptation du "bearer" (CSD, GPRS, SMS) ; par exemple si un fournisseur 
de service "push" constate que le reseau GPRS est engorge, il peut alors 
decider d'employer la technique "push" via SMS ; 

- I'adaptation du format du contenu ; si par exemple I'utilisateur n'est pas 
occupe mais que son SGSN est fortement charge, il est possible d'adapter le 
contenu a envoyer (suppression des images, modification du format HTML vers 
le format WML) de facon a limiter le temps de chargement du contenu pour 
I'utilisateur. 

II doit etre evident pour les personnes versees dans I'art que la 
presente invention permet des modes de realisation sous de nombreuses 
autres formes specifiques sans I'eloigner du domaine d'application de 
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I'invention comme revendique. Par consequent, les presents modes de 
realisation doivent etre consideres a titre d'illustration, mais peuvent etre 
modifies dans le domaine defini par la portee des revendications jointes, et 
I'invention ne doit pas etre limitee aux details donnes ci-dessus. 
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REVENDICATIONS 

1 . Procede de transmission de donnees dans un reseau telephonique de 
transmission de donnees (1), depuis un serveur (3) vers au moins un terminal 
(1 1) du reseau, caracterise par le fait que : 

- le serveur (3) acquiert, en provenance d'organes de transmission de 
trafic du reseau (1), des informations d'etat du reseau (1), et 

- le serveur (3) compare les informations d'etat du reseau a au moins un 
critere pre-etabli d'etat du reseau (1), pour retarder la transmission des 
donnees tant que I'etat du reseau (1) ne repond pas a au moins un 
critere d'etat. 

2. Procede selon la revendication 1, dans lequel le reseau (1) determine 
des informations d'etat specifiques a I'activite telephonique du terminal (11) et 
les fournit a titre d'informations d'etat du reseau. 

3. Procede selon la revendication 2, dans lequel le reseau (1) determine, 
comme informations specifiques au terminal (11), au moins I'un des types 
d'informations suivants : 

- etat de charge de trafic d'un centre de commutation auquel est rattache 
le terminal, 

- etat d'accessibilite du terminal, 

- etat d'occupation du terminal, 

- debit montant du terminal vers le centre de commutation, 

- debit descendant du centre de commutation vers le terminal, 

- qualite de service allouee au terminal. 

4. Procede selon Tune des revendications 1 a 3, dans lequel le reseau 
(1) surveille des changements des informations d'etat et emet 
automatiquement, a destination du serveur (3), une notification de changement 
d'etat necessitant un rafraTchissement des informations d'etat precedemment 
acquises. 
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5. Precede selon la revendication 4, dans lequel le reseau (1) notifie la 
necessite du rafraichissement par transmission des informations d'etat ayant 
change. 

6. Precede selon Tune des revendications 1 a 5, dans lequel I'acquisition 
5 des informations d'etat par le serveur (3) s'effectue a travers un gestionnaire (2) 

des informations d'etat. 

7. Procede selon la revendication 6, dans lequel le gestionnaire (2) regoit 
du reseau (1) et stocke les informations d'etat. 

8. Procede selon Tune des revendications 1 a 7, dans lequel le reseau 
10 (1) acquiert au moins une partie des informations d'etat aupres de centres de 

commutation du reseau (14, 15, 16). 

9. Procede selon la revendication 8, dans lequel chaque centre de 
commutation (14, 15, 16) du reseau stocke localement et transmet a 
destination du serveur (3), pour chaque terminal (11) rattache au centre, au 

15 moins Tun des types d'informations d'etat suivants : 

- identifiant unique du terminal (IMSI, MSISDN), 

- etat d'accessibilite du terminal, 

- localisation du terminal, 

- duree depuis le dernier transfert de donnees, 
20 - nombre de contextes PDP 

- adresse allouee 

- niveau de qualite alloue, 

- trafic montant, 

- trafic descendant. 

25 10. Procede selon la revendication 9, dans lequel les centres (14, 15, 16) 

surveillent I'etat courant des informations d'etat pour les comparer a des 
informations d'etat precedentes stockees localement, afin, en cas d'evenement 
de changement d'etat, de rafraichir les informations stockees localement et de 
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declencher, a destination du serveur (3), une emission des informations d'etat 
courantes. 

11. Procede selon la revendication 10, dans lequel les centres (14, 
15,16) surveillent I'apparition d'au moins I'un des types d'evenements suivants : 

5 - changement d'etat d'accessibilite du terminal, 

- rattachement a un autre centre, 

- changement de zone de routage, 

- debut, interruption ou fin d'un transfert de donnees, 

- renegotiation d'un niveau de qualite, 

10 - activation ou deactivation d'un contexte de liaison. 

12. Procede selon I'une des revendications 9 a 11, dans lequel la 
transmission, a destination du serveur (3), des informations stockees 
localement dans un centre (14, 15, 16) s'effectue sur requete. 

13. Procede selon I'une des revendications 1 a 12, dans lequel le reseau 
15 (1) acquiert au moins une partie des informations d'etat au moyen de sondes ( ) 

de surveillance de trafic disposees sur des arteres de communication (41 a 46) 
du reseau (1). 

14. Procede selon la revendication 13, dans lequel les sondes (51 a 56) 
analysent des champs de signalisation de messages transitant sur les arteres 

20 (41 a 46) de communication pour en extraire au moins certaines des 
informations d'etat concernant le terminal (11). 

15. Procede selon la revendication 14, dans lequel les sondes (51 a 56) 
analysent au moins I'une des signalisations suivantes : 

- requete de creation de contexte de liaison, 

25 - requete de mise a jour de contexte de liaison, 

- requete d'effacement de contexte de liaison, 

- requete de notification PDU, 

- requete d'emission d'informations de routage reseau, 
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- requete pour noter qu'un terminal est a nouveau joignable, 

- requete ^identification, et 

- requete de contexte SGSN. 

16. Procede selon Tune des revendications 14 et 15, dans lequel les 
5 divers messages etant transmis selon divers protocoles, les sondes (51 a 56) 

identifient un protocole utilise. 

17. Procede selon I'une des revendications 6 et 7, dans lequel le 
gestionnaire (2) requiert du reseau (1) des informations d'etat voulues. 

18. Procede selon la revendication 17, dans lequel le gestionnaire (2) 
10 commande, dans le reseau (1), la fourniture en retour d'informations de 

rafraichissement d'informations d'etat precedemment regues. 

19. Procede selon Tune des revendications 17 et 18, dans lequel le 
gestionnaire (2) surveille, dans le reseau (1), la disponibilite des informations 
d'etat et il commande le rafraichissement en cas d'indisponibilite de certaines 

is des informations d'etat. 

20. Procede selon Tune des revendications 18 et 19, dans lequel le 
rafraichissement n'est commande qu'apres reception, par le gestionnaire (2), 
d'une requete d'informations d'etat provenant du serveur (3). 

21. Procede selon la revendication 20, dans lequel le gestionnaire (2) 
20 determine une duree de stockage des informations dont il dispose et il n'en 

commande le rafraichissement que si la duree de stockage depasse un seuil 
de peremption. 

22. Procede selon I'une des revendications 17 a 21, dans lequel le 
rafraichissement des informations d'etat est commande par envoi, dans le 

25 reseau (1), de stimuli d'activation du terminal (11). 

23. Procede selon la revendication 22, dans lequel les stimuli sont emis 
vers le terminal (11) pour I'activer afin de provoquer I'etablissement d'un 
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contexte d'une nouvelle liaison de donnees dans le reseau (1), et de detecter le 
contexte de liaison pour effectuer un rafraichissement des informations d'etat 
du reseau specifiques au terminal (11). 

24. Procede selon la revendication 23, dans lequel les stimuli activent 
5 une application du terminal (1 1 ). 

25. Procede selon la revendication 24, dans lequel les stimuli activent 
une application SIM Toolkit. 

26. Procede selon Tune des revendications 24 et 25, dans lequel des 
stimuli de deactivation de I'application sont ulterieurement etnis. 

,o 27. Procede selon la revendication 23, dans lequel les stimuli atteignent 

d'abord un centre de commutation (17, 18) du reseau (1) et lui commandent de 
les transformer en un message emis d'activation du terminal (11), lui notifiant 
qu'il doit appeler un centre (17, 18), pour y recuperer des donnees. 

28. Procede selon I'une des revendications 1 a 27, dans lequel le 
is serveur (3) est fonctionnellement integre dans un reseau de signalisation 

semaphore gerant le reseau telephonique (1). 

29. Procede selon I'une des revendications 1 a 28, mis en oeuvre dans 
un reseau radio (1). 

30. Gestionnaire d'informations d'etat d'un reseau telephonique (1) pour 
20 la mise en oeuvre du procede de la revendication 1 , comportant des moyens de 

gestion (21, 22, 23) agences pour recevoir des informations d'etat du reseau 
(1) et les retransmettre a des serveurs de donnees d'information (3). 

31. Gestionnaire selon la revendication 30, comportant des moyens (21, 
221) d'interrogation sur I'etat du reseau. 
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32. Gestionnaire selon la revendication 31, comportant des moyens 
d'activation (21, 222) agences pour lancer dans le reseau (1) des stimuli de 
rafraTchissement des informations d'etat. 

33. Gestionnaire selon I'une des revendications 30 a 32, comportant des 
moyens (21, 223) d'agregation d'informations d'etat du reseau, afin de fournir 
des donnees de synthese de I'etat du reseau. 

34. Gestionnaire selon Tune des revendications 30 a 33, comportant des 
moyens (21, 224) d'integration, dans le temps, d'informations d'etat du reseau, 
afin de fournir des donnees de synthese de I'etat du reseau. 
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